Systems and Methods for Mobile Design Automation

ABSTRACT

Embodiments of the present invention include systems and methods for performing design automation on a mobile computer system. In one example embodiment the present invention includes a computer-implemented method comprising storing design automation data on a mobile device, displaying a plurality of design automation process steps to a user, the plurality of design automation process steps guiding the user through a design automation process for a project, receiving design automation input data from the user in the mobile device for a plurality of the design automation process steps, executing one or more data processing algorithms specific to at least one of the design automation process steps, and generating output data for the design project.

BACKGROUND

The present invention relates to computing, and in particular, to asystems and methods for mobile design automation.

In computer aided design automation (“design automation”), computers areused to design a wide variety of real world systems, objects, anddevices. Everything from semiconductor integrated circuits to jumbo jetsor spacecraft are commonly designed using design automation software.Construction is another example field where design automation has beenemployed. FIG. 1 illustrates design automation in a typical constructioncontext. In the construction context, engineers and drafts peopletypically work to prepare electronic designs for a construction project101 in a main office 102 of a construction organization using localcomputers 103. The computers may execute design automation software suchas a computer aided design (“CAD”) program, for example, to designvarious aspects of the construction project. CAD programs may be used todesign residential homes, office buildings, factories, or even bridges,dams, or other infrastructure projects.

One type of construction project that exemplifies the limitations oftraditional uses of CAD programs is a solar energy project. In a typicalsolar energy project, a salesperson may first visit a home to meet apotential customer. The salesperson may take notes on what thecustomer's preferences are for the solar energy system. Next, an auditor150 may visit the customer to perform an energy audit of the home. Theauditor may gather further data on the home's energy usage profile anddetails of the home's construction as a precursor to installation of asolar energy system in the home. Finally, a construction crew mayinstall a solar energy system at the construction site.

Typically, as employees of a solar energy vendor make repeated trips toa customer's home, data is collected and presented to engineers back atthe main office to be used to design the solar energy system. Forexample, engineers at the main office 102 may use a CAD programoperating on main office computers 103 to model relevant portions of thehome and create documentation for proper installation of the solarenergy system at the construction site.

One problem with existing approaches to design automation is thephysical separation between the engineering specialists using theautomation software and the location where the design problems are beingaddressed. The separation of engineering from a construction site, forexample, may result in several problems, including increased costsstemming from multiple additional employees visiting the site to relayinformation back to the engineering team and disconnects resulting frominaccurate or incorrect assessments of the site that result in erroneousdesign documentation. For instance, the employees who typically engagein customer contact are typically sales people and/or fields crews nottechnically trained to the level of engineers at the main office, andsending experienced engineering teams to every customer project may beextremely costly and inefficient.

More generally, separation between customers having engineering problemsto be solved and the main offices where engineering specialiststypically perform design automation leads to increased costs, slowerdesign times, and an increased likelihood of errors in the designprocess.

Embodiments of the present invention improve design automation byproviding systems and methods for mobile design automation.

SUMMARY

Embodiments of the present invention include systems and methods forperforming design automation on a mobile computer system. In one exampleembodiment the present invention includes a computer-implemented methodcomprising storing design automation data on a mobile device, displayinga plurality of design automation process steps to a user, the pluralityof design automation process steps guiding the user through a designautomation process for a project, receiving design automation input datafrom the user in the mobile device for a plurality of the designautomation process steps, executing one or more data processingalgorithms specific to at least one of the design automation processsteps, and generating output data for the design project.

The following detailed description and accompanying drawings provide abetter understanding of the nature and advantages of the presentinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a typical design automation scenario.

FIG. 2 illustrates mobile design automation according to one embodimentof the present invention.

FIG. 3 illustrates mobile design automation software according to oneembodiment of the present invention.

FIG. 4 illustrates a mobile design automation process according to oneembodiment of the present invention.

FIG. 5 illustrates a mobile design automation process according to oneembodiment of the present invention.

FIG. 6 illustrates a graphical user interface according to oneembodiment of the present invention.

FIGS. 7A-B illustrate master template customization according to oneembodiment.

FIG. 8 illustrates customized CAD according to one embodiment.

FIG. 9 illustrates a mobile design automation process according to oneembodiment of the present invention.

FIG. 10 is an example of a graphical user interface for adjustingdimensions according to one embodiment of the present invention.

FIG. 11 is an example of a graphical user interface for addingobstructions according to one embodiment of the present invention.

FIGS. 12-15 are examples of graphical user interfaces for assigningmounting planes according to one embodiment of the present invention.

FIG. 16 is an example of a process for determining stringing of solarpanels according to one embodiment of the present invention.

FIG. 17 is an example of a graphical user interface for specifyingmounting plane structure according to one embodiment of the presentinvention.

FIG. 18 is an example of a graphical user interface for specifyingelectrical information according to one embodiment of the presentinvention.

FIG. 19 is an example of a graphical user interface for selectingelectrical components according to one embodiment of the presentinvention.

FIG. 20 is an example process for specifying electrical componentsaccording to one embodiment of the present invention.

FIGS. 21A-B are examples of graphical user interfaces for configuringconduit according to embodiments of the present invention.

FIG. 22 is an example of a graphical user interface for specifying asafety plan according to one embodiment of the present invention.

FIG. 23 is an example of engineering escalations according to oneembodiment of the present invention.

FIGS. 24-25 are examples of templates according to embodiments of thepresent invention.

FIG. 26 is an example of input and output relationships for a solarproject mobile design automation software system according to oneembodiment of the present invention.

FIG. 27 illustrates hardware of a special purpose computing machineconfigured with a mobile design automation process according to oneembodiment of the present invention.

DETAILED DESCRIPTION

Described herein are techniques for performing mobile design automation.The apparatuses, methods, and techniques described below may beimplemented as a computer program (software) executing on one or moremobile computing devices, such as a laptop computer, a tablet computerwith a touch screen input, or handheld mobile computer, for example. Thecomputer program may further be stored on a computer readable storagemedium or reside on a remote server that may be connected to by a mobiledevice. The computer readable medium may include instructions forperforming the processes described below. In the following description,for purposes of explanation, numerous examples and specific details areset forth in order to provide a thorough understanding of the presentinvention. It will be evident, however, to one skilled in the art thatthe present invention as defined by the claims may include some or allof the features in these examples alone or in combination with otherfeatures described below, and may further include modifications andequivalents of the features and concepts described herein.

FIG. 2 illustrates an embodiment of the present invention. In oneembodiment, the present invention includes a mobile computing device 203executing design automation software that allows a user 202 to designfeatures of a project at the remote project site 201 (i.e., away from amain office). While embodiments and examples of the present inventionare discussed in terms of construction projects and solar energyprojects, it is to be understood that particular features and examplemay be advantageously used in a variety of other mobile designautomation applications where a user enters information into the mobiledevice at a remote project site and generates a design typicallyproduced by engineers or specialists at a main office.

FIG. 3 illustrates mobile design automation software according to oneembodiment. In one embodiment, mobile design automation software 301simplifies the design process and guides the user through the stepsrequired to complete the design. Mobile design automation software 301may have data and process steps that are customized for a particulardesign process to guide a user through a series of process steps withdesign intelligence encoded in the software. In this example, mobiledesign automation software 301 includes process steps 302, 303, 304, and305. In one embodiment, a user may perform each process step. Eachprocess step may solicit specific data associated with the particularproject and the particular process step being performed. Requested inputdata from the user may also be based on a process step specificalgorithm operating on pre-stored data for the particular project, whichdetermines the additional data required from the user to complete thealgorithm. The user may enter data corresponding to the project and theparticular process step into mobile design automation software 301, andmobile design automation software may execute a process step specificalgorithm to determine if the process step is completed correctly. Inone embodiment, the user is only allowed to move from one process stepto the next if a previous process step is completed correctly (orreturns a valid result). In some embodiments, particular steps may beskipped even if they are incomplete—steps that are purely data entry andaren't necessarily required to move the audit forward. In otherembodiments, the program may be stateless, where data can be entered atany point and the necessary calculations/decisions are performed foreach task, for example. In one embodiment, the mobile design automationsoftware may determine that each completed process step is valid using aprocess step specific algorithm. Embodiments of the present inventionmay include validation algorithms for each process step that determineif required data has been entered and if data processing results thatuse the required data for the process step return valid results.Accordingly, a user may be guided through the design process in a seriesof carefully crafted process steps for a specific type of project, whereeach step can only be validated if the user enters valid inputs for thestep. An example of project specific steps is illustrated below forsolar energy projects.

FIG. 4 illustrates another embodiment of the present invention. At 401,design automation data is stored on a mobile computing device. The usermay load a wide variety of data specific for a particular type ofproject on the mobile device before visiting the remote site, forexample. In one embodiment, metadata specifying project requirements maybe uploaded to the software system. In a construction context, metadataspecifying project requirements may include a list of requirements for atype of project (e.g., requirements of an authority having jurisdiction(AHJ) for a solar project as described in more detail below, or a listof common building stock in that area, or snow, wind, or seismic loaddata) with a Boolean value or a quantitative value associated with eachrequirement to specify whether the requirement applies to the particularproject being worked on or to what degree. For example, the mobiledevice may determine that one or more projects are in a particularjurisdiction and apply one more applicable AHJ rules to all projects inthe particular jurisdiction. At 402, the user may activate the mobiledesign automation software on the mobile device and the designautomation process steps are displayed to the user. At 403, designautomation input data is received from the user. The input data may bereceived in response to specific algorithms for process steps for aparticular type of project. At 404, a data processing algorithm forparticular process steps may be executed to process the received dataand possibly prestored data, for example. At 405, output data for thedesign project is completed. For example, the user may enter data ateach process step, an algorithm operates on the input data and validatesthe process step, and when all the process steps are completed, thesystem generates a project output (e.g., design documents). At 406, thedata for the project, and generated project outputs, may be loaded intoa backend system at the office. For example, in one embodiment data fora particular project may be loaded into multiple backend systems tocreate a physical manifestation of the design, order required materialsfrom third parties, schedule personnel, tools, and other resources, andcreate entries in a finance and accounting system to account for thecosts and potential revenues of the project, for example.

FIG. 5 illustrates another embodiment of the present invention. At 501,a user may activate mobile design automation software on a mobiledevice. At 502, the software system may access design automation datastored on the mobile device, such as customized data for a particularproject the user is working on (e.g., entered by others into thedatabase earlier in the conversation with the customer) and preloadeddata corresponding to different user specified options in the software,for example. At 503, process steps for the project are displayed to theuser.

In some embodiments, the software can step a person in the field (e.g.,an auditor) through the design process (e.g., an audit) in the mostefficient way possible depending on the context of what the userobserves on site. The user enters data into the system about the designconstraints obtained on site, and the data constrains the design processsteps that the user can execute. For example, in one embodiment, theremote design process may be structured as a decision tree to step theuser through only the steps or questions relevant to a particularproject for a particular customer (e.g., as determined by responses toearlier questions and data loaded into the system for a particular job).

FIG. 6 is an example graphical user interface (GUI) according to oneembodiment. When the user activates the mobile design automationsoftware, the mobile device may display GUI 600. GUI 600 includes a mainprocess user interface (UI) 601, design area 602, and multiple processstep specific UIs 603A-N. Main process UI 601 may include icons formultiple process steps 610-613. A user is guided through the differentprocess steps by clicking of the different icons 610-613, whichrepresent N different process steps, where N is an integer. Whendifferent process step icons are accessed, UI 600 displays differentprocess step specific UIs. For example, when a user selects process step610, UI 600 displays process step specific UI 603A, when a user selectsprocess step 611, UI 600 displays process step specific UI 603B, when auser selects process step 612, UI 600 displays process step specific UI603C, and when a user selects process step 613, UI 600 displays processstep specific UI 603N. Each process step specific UI comprisessub-process step icons for accessing pre-defined functionalityassociated with the particular process step. For example, process stepspecific UI 603A includes icons 621-623 representing M differentfunctions associated with process step 610, where M is an integer.

Referring again to FIG. 5, when the process steps are initiallydisplayed, a user may select a process step at 505. In one embodiment,the system may require that the process steps be selected sequentiallyso that the user is guided through the design process according to apredetermined sequence of steps. A selection control step 506 may, insome embodiments, prevent the user from selecting process steps beforeother prerequisite processes have been completed. For example, whenprocess step 610 is selected (FIG. 6), the software system may invokethe first process step at 510 (FIG. 5). Accordingly, GUI 600 may displayUI 603A, which includes process step specific icons 621-623.

At 511 in FIG. 5, data inputs from the user specific to the firstprocess step may be received. For example, UI 603A may include dataentry fields or data creation mechanisms. Alternatively, different icons621-623 may invoke different sub-processes including data entry fieldsor invoking different specific data creation mechanisms associated witha particular process step specific icon (e.g., specific CAD functions).Further, at 512 in FIG. 5, one or more data processing algorithms forthe first process step 610 may be executed at 512. Referring to FIG. 6,invoking UI 603A may invoke a particular algorithm for processing data,or invoking one of icons 621-623 may invoke different sub-processalgorithms for processing data. For example, in one embodiment designarea 602 may include a computer aided design (CAD) program and accessingprocess step 610 may activate limited features of the CAD program, andicons 621-623 may invoke different specific features of the CAD programfor simplifying creation of a design according to a simplifiedstep-by-step/function-by-function approach for manipulating data. As aparticular example, accessing process step 1 icon 610 may cause thesystem to retrieve a basic schematic (e.g., engineering drawing) of aparticular project. Each of icons 621-623 may invoke a particularfeature of a CAD program for manipulating the schematic one feature at atime to allow a user to adjust the schematic and enter data available atthe remote project site. By limiting features and data entry toparameters only available at the remote project site, for example, thesystem guides the user through the process without requiring (or in somecases allowing) the user to manipulate a broader range of parametersmore thoroughly understood by an expert at the main office. The useracts to enter and verify data available at the remote project sitewithout being required to perform a full and complete analysistraditionally performed by highly trained experts in the main office,for example.

In some embodiments, process step algorithms may include rules fordetermining if an engineering escalation is to be generated. Forinstance, after execution of algorithm 512, a step 507 may check theinput data and determine if the data received from the user andprocessed by the algorithm resulted in an engineering escalation. Anengineering escalation may occur if the input data does not passparticular predefined criteria for the check. For example, anengineering escalation may occur if the input data is out of range,unavailable, or if manipulation of the parameters of the schematic inthe design area violates a predefined rule. In some embodiments,engineering escalations may occur if certain pre-defined scenarios aremet (e.g. a certain type of panel or roof type is encountered, or wheremore detailed structural calculations may be required to determine thebest way to safely install a system). If the user's input triggers anengineering escalation, an entry may be generated for the escalation at508. For example, a new field of a database or new line of a textdocument may be generated describing the nature of the engineeringescalation. A plurality of rules for predefined functions of eachprocess may have particular corresponding engineering escalations thatare created if the rules are violated to ensure the data entered intothe software by the user results in a proper design. If any one of therules is violated, a corresponding specific engineering escalation maybe generated so that the design may be reviewed by specialists in themain office to ensure quality of the design. Further, at 509, eachprocess step may be checked to determine if the process step iscomplete. If the process step has been completed and the input data isvalid (e.g., no engineering escalations), then a process status may beset at 599. A status indicator for each different process step may allowcontrol step 506 to enable and disable access to different processsteps, for example. Once a process step is completed, GUI 600 may updatethe displayed icons, by changing the color of the completed process stepfrom Red to Green, for example, at 503 and the user may select the nextprocess step at 505.

According to the above description, a user may select (e.g.,sequentially) other process steps. For example, a user may invoke thesecond process step at 520, receive input data specific to the processstep at 521, execute a process specific data processing algorithm at522, check for engineering escalations at 507, and set the processstatus at 599. Similarly, a user may invoke the additional process stepsto the final process step at 530, receive input data specific to eachprocess step including the final process step at 531, execute a processspecific data processing algorithm for each process step including thefinal process step at 532, check for engineering escalations at 507, andcheck the process status at 509. While steps 507 and 509 are illustratedhere as along a common path for the different process steps, it is to beunderstood that some embodiments may use different procedures fordetermining escalations and process completeness. In some embodiments,escalations and process completeness may be incorporated into theprocess specific algorithms, for example, and may be illustrated withthe specific process step. Referring to FIG. 6, as different processstep icons 611-613 are selected, different process specific UIs aredisplay to the user with different data entry fields and/or functionsfor processing data according to each process step.

Some embodiments of the present invention may operate on customizedtemplates that are loaded into the electronic device before a job isperformed. For example, some types of jobs (projects) may have a numberof previously known component options that are used in the project. Asillustrated below as an example, design documents for a solar powerproject may have a number of known blocks in the schematics that areused across multiple implementations. In one embodiment, a mastertemplate includes a superset of multiple design blocks for a schematic.The master template may be customized by either deleting blocks that arenot required for a particular project or adding project specific blocksused in a particular project. Example blocks are computer aided designblocks (CAD) used in a program such as AutoCad, for example. Blocks mayinclude components of design plans or schematics such as text blocks,blocks having particular attributes, or representations of one or moreelectrical or physical components (e.g., inverters, wires, beams), forexample.

FIG. 7A illustrates master template customization according to oneembodiment. In this example, a master template 711 includes a pluralityof CAD blocks (e.g., B1-B8). The master template may be customized for aparticular job by deleting blocks unnecessary for the particular job oradding job/project specific CAD blocks to a custom template 714.Addition and subtraction of blocks is illustrated at 713. One or morecustom templates 714 may be loaded into mobile design automationsoftware 715 for use on corresponding projects. In one embodiment,design requirements for a particular project are accessed and used tomodify the custom template. Design requirements may be stored on acomputer system, such as in a database 710, for example. Designrequirements may include rules to determine if a particular block fromthe master template is to be removed or if a project specific block isto be added to the custom template. In one embodiment, attributes of aparticular job are analyzed using such rules to determine particularblocks to be added to or deleted from the master template. Designrequirements may pertain to information about a particular authorityhaving jurisdiction (AHJ). For example, a particular city may require aparticular size of paper for the design plans, setbacks, notes, or otherparticularities. Project specific blocks may be stored in database 710or at a specified location on the computer system, for example.

One example process for customizing a template is shown in FIG. 7B. At750, the master template is accessed. At 751, design requirements andinformation for a particular job are retrieved. At 752, rules areapplied to link design requirements to particular jobs. For example, thesystem may used a job ID to determine a State in which the job is beingperformed. A particular rule may indicate that if a job is inCalifornia, then a particular text field should be included in aparticular notes section of the plan documents. In this case, the systemmay access a block including the particular text used for Californiajobs. At 753, blocks are added to or deleted from the master template.Continuing the example above, the system inserts the project specificblock into the custom template at a specified location. Once all thedesign requirements have been processed, the system outputs a customtemplate, which may be loaded into mobile design automation software 715for use on the particular job.

FIG. 8 illustrates customized CAD according to one embodiment. In someembodiments, the user interface for designing a project in the field maybe customized to support a predefined set of user input actionscorresponding to particular CAD functions, which may be correspond tosimple commonly used functions anticipated for designing a particulartype of job. As illustrated in FIG. 8, a set of user input actions maybe mapped to one or more particular CAD functions. In particular, thesystem may only allow a user to perform certain predefined input actionsin the user interface as illustrated at 801, such as placing a designcomponent, connecting the design component, or entering particular datafor the design component. However, some user input actions may notdirectly cause CAD functions to implement the desired user input action.Rather, a user input action may be mapped to multiple CAD functions at802. Multiple CAD functions may be used to manipulate a model 803representing the design (e.g., an electrical model or structural model)or such CAD functions may be use to manipulate the custom template 804,or both. For example, a particular user input action may select thecross section cut of a roof that a user might like to show. All userdoes is place the line at the appropriate place on the roof. This singleuser input is automatically mapped to the following CAD functions: thearchitectural representation of section views are automaticallygenerated on a site plan; a front section view is automatically created(with blocks and lines in CAD); standoff detail is automaticallycreated, as well as some standard BOM parts (e.g., this may be a singleblock); and a side section cut is automatically generated. The systemmay automatically place the multiple CAD blocks in appropriate placesbased on where they are drawn in the site plan by the user, for example.Further, the system may perform checks on model 803 and custom template804 (e.g., as they are modified) to determine if execution of the CADfunctions corresponding to a user input action results in an engineeringescalation.

Example Application and Implementation Solar Power Installation

FIG. 9 illustrates a process for using a mobile computing device toperform a solar power installation project. In a solar powerinstallation project application, a field technician, for example, mayload a mobile device with data for a particular installation project ata particular installation site and use the mobile device to executesoftware performing at least some of the features described above toobtain the information required to install a solar power system at thesite. In particular, a technician may audit the job site and enter in avariety of data about physical attributes of a solar power installationat a particular installation site. The data may be used to tailor thesolar power system to the physical attributes of a particularinstallation site and to generate installation documentation fordesigning, permitting and installing the solar power system, forexample. Features and advantages of the present invention include usinga mobile device loaded with data and specialized software to allow atechnician to perform a job site audit to generate a complete set ofinstallation documentation (e.g., construction documents) withengineering involvement reduced or entirely eliminated. While thefollowing example illustrates an application in the context of aresidential solar energy system project (or photovoltaic “PV” system),it is to be understood that other embodiments may be used in a widerange of applications. As further example energy projects, someembodiments of the present invention may be used in electric vehiclecharging projects, energy storage projects, energy efficiency project,solar hot water projects, metering/monitoring projects, or buildingcontrols and automation projects to name just a few.

An overview of the process is illustrated in FIG. 9. At 1101, the fieldtechnician (or auditor or just “user”) connects to a network at the mainoffice. At 1102, the user starts the audit software and either creates acustomer job or loads an existing customer job that needs a site audit.At 1103, data for a particular site audit may be loaded to the mobiledevice. For example, in one embodiment the user may load a schematicsite file onto the mobile device, such as a Precigeo file, where solarand roof schematics are obtained through the analysis of aerial imagery,for example. The user may further load information pertaining to anauthority having jurisdiction (“AHJ”) as mentioned above. Typical AHJsinclude state, county, or city governments or utility companies, forexample. AHJ files may include specific requirements for physicallylocating certain objects on a property or how equipment is to beinstalled or configured, for example. Appendices A and B illustrate twoexample metadata files loaded to the mobile device. Appendix Aillustrates AHJ metadata for electrical and Appendix B illustrates AHJmetadata for mounting planes. As illustrated in Appendix A and B, dataloaded from a main office computer may include AHJ data, projectspecific data, and financial data, for example. AHJ requirementsapplicable to a particular project are listed between“AHJAuditNotes_Key” followed by a value marked as TRUE or FALSE. If anAHJ requirement is followed by a value set to TRUE, then the particularAHJ requirement is applicable to the particular project. A value ofFALSE indicates that the particular AHJ requirement is not applicable tothe particular project. Other data imported into the mobile device isillustrated in Appendix A and B. Names of the example variables in theattached appendices are representative of each variables use within thesystem.

At 1104, the user arrives at the site and loads the job from a job list.A user may perform many audits between visits to the main office,thereby increasing efficiency of labor usage, and so data for multipledifferent audits may be stored on the mobile device for the user toselect. At 1105, the user performs the audit as described in more detailbelow. At 1106, data for the complete audit may be transferred back tothe main office computer network for integration into other softwaresystems (e.g., a supply chain management software system) andcoordination of the actual installation. Appendices C and D illustrateexample metadata files provided from the mobile design automationsoftware to a backend system.

FIG. 10 illustrates a process according to one example embodiment. Inthis example, a software system executing on a mobile device generatesGUI 1200. GUI 1200 includes a main menu 1201, process step specific userinterface 1202, and a design area 1203. Mobile automation designsoftware may include a CAD program to create a project in the designarea 1203 based on icons in process step specific interfaces, forexample. Main menu 1201 displays icons (or buttons) 1210-1214 and1220-1228. Icons 1220-1228 corresponds to different solar powerinstallation design process steps. In this example, the solar powerinstallation design process steps include adjusting dimensions at thesite 1220, adding obstructions 1221, specifying mounting planes 1222,specifying mounting plane structure 1223, entering electricalinformation 1224, configuring electrical components 1225 (e.g., Balanceof System), drawing conduit 1226, specifying a safety plan 1227, andgenerating installation documentation 1228 (e.g., a PDF of a plan set).Each of the above example process steps is described in more detailbelow. Further, menu 1201 includes an icon 1210 for displaying AHJnotes, an icon for opening a new project 1211, an icon for viewingengineering escalations 1212, an icon for exporting data out of thesystem for further analysis 1213, and an icon for saving data in theproject 1214. The solar power installation process steps each includelimited partitioned functionality to guide a user through a solar powerinstallation process for a project as illustrated by this example in thefollowing Figures. At different steps, the user may be prompted forparticular data inputs to generate complete installation documentationwith reduced engineering support.

As illustrated in more detail below, in some embodiments differentprocess steps may have different associated user interfaces and may havedifferent associated data processing algorithms. For example, when auser selects the adjust dimensions icon 1220, a user interface 1202 isdisplayed to the user. Additionally, the design area 1203 may include aschematic of the project (here, a schematic of a home) imported into theproject from the main office, for example. In this example, theparticular process step specific user interface 1202 for the adjustdimensions icon 1220 includes additional icons and algorithms foradjusting dimensions of an installation site. For example, interface1202 includes a graphic 1230 displaying the same graphic as icon 1220 toassociate interface 1202 with icon 1220. Interface 1202 further includesa rotate icon 1231 to rotate the design through a range of orientationangles, a move walls or nodes icon 1232 to adjust the dimensions of thestructure to place walls or corners are specified locations at the site,an add new building lines icon 1233 to add building lines to representactual building structural configurations that are observed at the sitebut which do not appear in the schematic of the structure (i.e., asreceived from the main office), and tape measure icon 1234 to measuredistance between points in the schematic and verify the schematicagainst actual measurements taken at the site. Accordingly, each iconactivates functionality to receive additional information about theproject based on data most readily available, if not exclusivelyavailable, at the site. The user may advantageously tailor the designdocuments at the site with a simplified interface.

Interface 1202 further includes a delete button for deleting data fromthe project and redo and undo buttons 1236. Finally, in this example,when a user has performed any one or more of the desired functionsassociated with process step specific user interface icons 1231-1234,the user may select the lock icon 1237. In this example, when the lockicon is selected, the user signals to the system that the particularprocess step is complete and the corresponding icon in the main menuchanges color to indicate the step is complete. Changes in color may befrom red to green, where red indicates a process step is not completeand green indicates a process step is complete, for example. In oneembodiment, the lock button completes verification of the current stepand applies design automation processing associated with the designstep. The processing that the lock button performs is related to theparticular process step.

Design area 1203 displays the solar power installation project. In thisexample, a schematic top view of a residential home is illustrated(e.g., from a Precigeo file). In other embodiments, other schematics ofother types of projects may be shown. The basic schematic may be thestarting point for a design. As the user moves through each of theprocess step icons, the user may be prompted to enter more data todesign the solar power system to be installed at the site, includingsite specific information such as the physical attributes of itemsincluding physical attributes shown in the examples below.

FIG. 11 illustrates a process to add obstructions according to oneexample embodiment. In this example, a user may audit the roof of a homeand identify certain obstructions in the roof, such as a chimney, askylight, ventilation pipe, antenna/dish, etc. . . . using interface1300. In this example, when a user selects the add obstruction button1221, an interface 1301 for adding obstructions is displayed. A user mayfirst select an “insert origin” button 1310 to set an origin 1312 (“X1,Y1”) in the design area. Positions of obstructions added to the designarea may be specified relative to origin 1312. In this example, twoorigins 1312 and 1314 are added for two different structures at thesite. A user may add obstructions for each structure by selecting therelevant origin and entering information about the obstruction. Forexample, a first obstruction 1324 may be identified as a chimney byselecting radio button 1350. Once the data for chimney 1324 is entered,a user may select the Insert button 1320 (for new obstructions) or theUpdate button 1321 to update data for an existing obstruction. Thechimney is shown as obstruction “A” in the menu 1324. Obstructions maybe deleted by selecting the delete button 1322. Other exampleobstruction types illustrated are skylight and the locations of solarmeasurement readings. This example project includes a skylight 1325 andsolar reading 1326.

In one embodiment, when the obstruction type is a solar measurementreading (e.g., Solmetric 1351), interface 1301 may generate an inputfield for receiving a solar reading. Solar readings may be conductedusing a shade analysis tool, such as a tool by Solmetric, Inc., forexample, which produces a measurement tool with a fisheye camera and adedicated on-board processor to perform digital image processing andanalysis to compute shading and solar access percentages and may includean electronic compass and inclinometer enabled to measure roof pitch andazimuth, for example.

The obstruction may also be identified by a general shape, such ascircle or rectangle, for example. Additional physical parameters for theobstruction received through obstruction interface 1301 may include anX-coordinate in feet (ft) and inches, a Y-coordinate in feet (ft) andinches, a height of the obstruction, a description, a width, and length,for example.

When a user has completed adding obstructions for a particular project,the user may select the lock button 1323. When the lock button 1323 isselected, the add obstruction icon 1221 may change color signifying thatthe process step is complete.

FIG. 12 illustrates a process to assign mounting planes according to oneexample embodiment. In this example, a user may audit the roof of a homeand identify certain areas of the roof where solar panels may bemounted. Particular portions of a roof where solar panels may be mountedare referred to as mounting planes. A mounting plane may be a singleplanar segment of a roof, for example. A roof may have one or multiplemounting planes that could be used to support a solar system. In oneembodiment, a user may select particular mounting planes of a roof forthe project in the design area and assign different mounting planes todifferent roof segments. In this example, when a user selects the assignmounting plane icon 1222, an interface 1401 for assigning mountingplanes is displayed. A user may first select an add mounting plane icon1410 to add a mounting plane in the design area. A new icon 1510 mayappear for assigning an area to the mounting plane as shown in FIG. 13.The user may select the area to assign to the mounting plane in thedesign area and designate a location for the mounting plane label to bedisplayed in the design area. The resulting mounting plane 1710 (MP1) isshown in FIG. 15.

Referring again to FIG. 12, mounting plane interface 1401 may allow auser to enter a variety of additional physical attributes about thespecified mounting plane, including azimuth, roof slope, number ofstories, whether a ladder is needed, roof maximum height, roof type(e.g., composite shingle), design notes for installers, and whether ornot there is attic crawl space for a conduit run, rigid insulation, orfire sprinklers, for example.

In this example, when the mounting plane is assigned using icon 1510,icon 1510 may change color, for example, and two additional icons 1610and 1620 are displayed to the user (See FIG. 14). Icon 1610 may be usedto assign a ridge and eave to the mounting plane to set the physicalorientation of the mounting plane. For instance, a user may select icon1610 and then mouse click on the upper edge of mounting plane MP1 to setthe ridge and then mouse click on the lower edge of mounting plane MP1to set the eave. FIG. 15 shows the designated ridge 1731 and eave 1730for an example project. Similarly, icon 1620 may be used to specifystructural changes that may occur in a single mounting plane.

Referring again to FIG. 13, the data for a particular project mayinclude information about the type of system sold to a particularcustomer. In this example, the customer was sold the following modules:24 YINGLI YL235P-29b—5640 Watts, where information about the solarpanels to be installed may be loaded into the mobile device from a salesprogram used by the sales team (e.g., at the main office).Alternatively, a user may mouse click module selection button 1420. Thesystem may prestore a plurality of module types available for selectionby a user. When module selection button 1420 is selected, the prestoredmodule types (e.g., module models and manufacturers) are displayed to auser and the user may select the module type that was sold to theparticular customer.

In this example, when the module type is selected, module selection icon1420 changes color to indicate that the step of the process iscompleted, and a new module drawing icon 1630 is displayed (See FIG.14). Module drawing icon 1630 allows the user to draw solar powermodules on a particular location of a mounting plan in the drawing area.For example, a user may draw solar power modules 1720 in FIG. 15 at aparticular location on mounting plane 1710. In one embodiment, data forthe project may include an AHJ filed used to limit the placement of thesolar modules. For instance, the AHJ may be used to determine a firesetback, for example. The system may further determine invalid moduleplacements based on physical and electrical rules limiting placement andconnectivity. For example, an AHJ may prohibit putting panels overbathroom plumbing vents. Thus, the auditor may be required to placepanels elsewhere. As another example, a home owners associate may notwant any panels to be seen from the street outside of the house. In thiscase, an auditor may be required to not place any panels on any mountingplanes tilted towards the street. As an electrical example, a utilitycompany may require that an AC disconnect be placed directly next to anyinverter. Accordingly, an auditor may be required to find a place thatcan fit both an inverter and AC disconnect on the wall of the building.As another electrical example, in some locations where there is extremeheat (e.g., Arizona), it may be unadvisable to place inverters on sunfacing walls. In this example, an auditor may be required to find aspace inside the garage to place the inverter.

In this example, as a user places modules on the mounting plane, thesystem automatically determines how many more modules are needed to meetthe energy requirements specified in the sale. For instance, as the userplaces modules on the mounting plane, the system may calculate theamount of energy generated by the currently placed modules and displaythe energy for currently placed modules and total amount of energyrequired, thereby indicating that additional modules are to be placed onthe mounting plane. Design status is shown at 1650 and may include anindication of the amount of power or modules needed to meet the systemrequirements, for example.

Features and advantages of some embodiments may include evaluation andconfirmation of design parameters. For example, in one embodiment aprocess step may include an algorithm that provides feedback to a userto indicate whether or not the design the user has entered is feasible,and may evaluate an optimum design if multiple design options exists. Inone embodiment, the system may receive inputs from the user on thephysical attributes of the design, attempt to disprove that a solutionexists, and then determine a best solution from existing solutions. Inthis example, the system performs an automated calculation of electricalstringing of the modules and notifies the user if the module design isnot feasible (e.g., if no stringing solution exists). If multiplepossible stringing solutions exist, the system may output the optimumstringing solution for the particular physical attributes of theproject. Strings typically comprise multiple modules connected in seriesof voltage potential (e.g., like AA batteries in a flashlight). Multiplestrings may be connected in parallel. Different strings typically havethe same voltage potential difference (e.g., string lengths are the samelength). The combined output of a string(s) is typically the input foran inverter. In some embodiments, a process step may include analgorithm for providing feedback to the auditor to indicate if thedesign has an electrically feasible stringing solution based on thestringing requirements of a particular module utilizing an invertersupply, ambient temperature of the region, and physical attributes ofeach mounting plane where the modules are placed. The individualelectrical characteristics of the modules result in the voltagedifference potential of each string. Further, each inverter has a rangeof potential input voltages. As long as the string voltage potentialfalls into the allowable range of the inverter the system will produceenergy. Some embodiments of the present invention may determine thevoltages from strings of modules and determine if the stringingconfigurations are compliant with a particular inverter, for example.

FIG. 16 illustrates an algorithm for analyzing stringing of solar panelmodules according to one embodiment of the present invention. In thisexample, string lengths are loaded at 1420. For example, the system mayload all possible string lengths for a module given a set of invertersfrom a supply chain and an ambient temperature. The result may produce alist of distinct possible string lengths, for example. Next, at 1421,the system may evaluate feasibility of the design. For example, arecursive check may be performed against the total number of modules inthe system to make sure the system level is solvable (e.g., if the userhas drawn 13 modules, but the module string lengths are {7 . . . 12},then no summation of a set of these numbers will get 13). At 1422 thesystem checks for invalid solutions and the user may be notified of aninvalid configuration at 1423.

At 1424, stringing groups may be generated. For example, in oneembodiment, all the mounting planes in the system may be parsed andcontained modules of like tilt and azimuth may be combined intostringing groups. Stringing groups are groups of modules that are ableto be combined into similar string lengths. Stringing groups maymaintain metadata on the position of each module and its associationwith the mounting plane and the stringing group.

Another evaluation of feasibility of the stringing groups may beperformed at 1425. For example, a similar recursive check on each modulegroup may be performed to make sure that it can be solved with the givenstring lengths. For instance, if there are 16 modules at a 170 degreeazimuth and a 20 degree tilt, and 13 modules at a 190 degree azimuthwith an 18 degree tilt, the 16 module group can be broken into twostrings of 8, but the 13 module group can't be broken down with thegiven string lengths. Some embodiments of the present invention maydisprove that a solution exists before actually solving for the bestsolution because such an approach is faster and when the systems becomesmore complex the design may have more solutions that don't work thansolutions that do. At 1426 the system checks for invalid solutions andthe user may be notified of an invalid configuration at 1427, forexample.

At 1428, the system determines the stringing solutions. For example, ifboth the checks in 1422 and 1426 have passed, then at least one solutionis available. Accordingly, the system may recursively determine everystringing solution per stringing group. For example, a stringing groupof 24 modules with available string lengths of {7 . . . 12} hassolutions of: [12, 12], [8, 8, 8], [7, 7, 10] (maybe more). All thesestringing solutions may be saved and associated with a particular stringgroup.

At 1429, an optimum stringing solution is determined. For example, afterthe possible stringing solutions for each stringing group are obtained,the system may figure out what is the ‘best’ solution for theinstallation crews. The general rules that govern the definition of bestmay include: fewest inverters, longest string lengths, and modules oflike strings lying close to each other. These three factors may beindicative of the shortest amount of time for installation, for example.Given all of the stringing groups and their possible string lengths, thesystem may combine and recombine all the strings of the design andassign every possible solution a weighted value. In one exampleimplementation, an equation that may be used is as follows:

(20*NUMBER_OF_INVERTERS)+((1+TOTAL_DELTA_OF_ALL_STRINGS)*NUMBER_OF_STRINGS)

For instance, in the example of a stringing group of 24 from above:

[12,12]=20*1+(1+0)*2=22

[8,8,8]=20*1+(1+0)*3=23

[7,7,10]=20*2+(1+3)*3=52

As a result, the optimum string length of [12,12] which is the lowestnumber may be generated and provided to the user. Example program codefor a particular implementation written in C# is illustrated in AppendixE attached hereto.

Returning to FIG. 14, when the required number of modules are placed onthe mounting plane to meet the target energy generation specificationwith a valid stringing solution, the system indicates that the moduledesign is complete. FIG. 15 shows a full set of modules 1720 placed in aparticular location on a mounting plane by a user for a particularproject. Similar to previous process steps, when the mounting plane isassigned and the module placed on the mounting plane, a user may selectthe lock icon 1640 (e.g., FIG. 14) to indicate that the mounting planeprocess step is complete, which causes the lock icon 1640 and mountingplane icon 1222 in FIG. 12 to change color indicating these steps arecomplete.

FIG. 17 illustrates a process to specify mounting plane structureaccording to one example embodiment. In this example, a user may auditthe physical structure of a roof and specify structural details of asupport structure under a particular mounting plane. For instance, whena user selects the mounting plane structure icon 1223, an interface 1810is displayed for specifying a mounting plane support structure. A usermay first select a particular mounting plane at 1811. In this example,mounting plane 1830 is selected. The user may select the mounting planetype in interface 1810 from a set of predetermined roof structure types,which in this example may be any one of pitched roof stick frame,pitched roof truss, or pitched roof vaulted.

The user may further select the draw structure icon 1821. Accordingly, agraphic representation of the support structure 1831 corresponding tothe selected mounting plane type is displayed in the design area.Further, the user may identify a location for a cut view. The cut viewsets the location of the cross section of the mounting plane to be usedfor specifying the structure under the mounting plane. A cut view 1899is illustrated between 1890 and 1891. In this example, pitched rooftruss was selected as the mounting plane type. Therefore, the systemdisplays a truss structure 1831 along the cut view 1899 under mountingplane 1830. Further, since pitched roof truss was selected, data entryfields for physical parameters of the truss structure are displayed tothe user, which include top chord dimensions, bottom chord dimensions,ridge size, truss spacing, eave and gable length, sheathing thicknessand, for a pitched mounting plane, web size, for example. It is to beunderstood that input fields for other physical parameters of otherstructure types may be provided in interface 1810. In this example, auser may further specify load bearing walls 1832 (LBW) by selecting addload bearing wall icon 1822. More generally, it is to be understood thatother structural parameters of other project types may be specified in asimilar manner. As before, the user may select the lock button when themounting plane structure is complete and the mounting plane structureicon 1223 may change color to indicate that this particular process stepis complete.

FIG. 18 illustrates a process to entering electrical propertiesaccording to one example embodiment. In this example, a user may auditthe site and enter the electrical attributes physically present at thesite by selecting add electrical information icon 1224 and enteringinformation into interface 1910. For example, the user may enterinformation about the main panel, electrical service, and main breakeras illustrated in FIG. 18. In one embodiment, the user may specify ifone or more physical parameters satisfies multiple predeterminedcriteria. For example, the user may specify if a gateway locationsatisfies multiple criteria including distance from inverter andelevation from inverter as shown in FIG. 18.

FIG. 19 illustrates a process to adding electrical hardware according toone example embodiment. In this example, a user may audit the site andenter and configure the electrical hardware required to install a solarenergy system. For example, when a user selects the add electricalhardware icon 1225, an interface 2210 is displayed for selecting andconfiguring electrical components for the project. This process is alsoreferred to as configuring the balance of the system (“Balance ofSystem”). In this example, the system automatically analyzes the solarmodules placed on the mounting plane and other electrical parameters anddetermines required electrical components for installing the system.

As mentioned above, embodiments may invoke an electrical stringingfunction to get an optimum installation stringing solution for theproject. This function may return the module string lengths (and totalnumber of those particular strings) with the associated photo-voltaic(PV) system, for example. In one embodiment, an electrical model may begenerated based on the stringing configuration. For example, the systemmay examine each group of string lengths and determine their totalpower. For instance, if there are 6 strings of 10 modules and eachmodule is 100 W, the total group is 6000 W. If the total power isgreater than the largest available inverter, the group of strings may becut in half, for example. In this example, if the largest inverteravailable in inventory is 5000 W, the system may break down the stringsinto two groups of 3 strings of 10 modules. In this example, given anoptimum solution of string lengths and a breakdown of stringing groupsinto power levels for available inverters, the system builds anelectrical model.

FIG. 20 illustrates a process that may be performed on strings of panelsaccording to one embodiment. For example, components may be determinedfor the DC side of the system for each inverter. At 2001, availableinverters are accessed, for example, in a table or database. Groups ofstrings may be tested against the accessed inverters. At 2002, aninverter may be selected based on a voltage range of the string ofpanels, for example. For instance, the system may find the inverter withthe best voltage window range for a particular string length. Invertersmay have different voltage windows and the system may select an inverterautomatically that can handle the power of the module strings and thevoltage range of the string.

Once the inverter is selected, the system may determine the electricalcomponents on the DC side at 2003. For example, the system may determineif a combiner box, junction box, or U-Joint connector is required, or ifno method of combination on the roof is to be used, for example. Anexample component selection algorithm is illustrated in Appendix F. Inone embodiment, the system may determine if a DC disconnect is need bychecking if the AHJ requires a handled DC disconnect. If a DC disconnectis required and the particular inverter being used does not have a DCdisconnect (as determined from the lookup table for the choseninverter), a DC disconnect icon (not shown) may be presented to the userfor selection and placement.

After the system has solved for the DC side of each inverter in thesystem under design, the system may determine the AC components. Ifthere are more than two inverters, the design may need a load center. Aload center combines the outputs of the inverters into a single wirepath. If a load center is required, a load center icon (not shown) maybe displayed to the end user, for example. The remaining AC Electricalcomponents requirements may be determined from the AHJ database. Thenecessity of AC disconnects and PV Meters may also be stored in our AHJdatabase, for example.

Once all the electrical components are determined by the system, DC andAC components are displayed to the user at 2004. In some embodiments,the system may determine required DC components, and display therequired DC components together with optional DC components and ACcomponents. Example components that may be displayed include aninverter, a distribution panel, PV meter, AC disconnect, load center(for multiple inverters), meter main, DC disconnect, junction box, andcombiner box, for example. In this example, a user may access an AHJ at2005 to determine if the AHJ requires components not required by theelectrical model. For example, an AHJ may require AC disconnects basedupon conditions at the job site. If the auditor determines that the ACdisconnect is necessary, he can simply draw one into the design area,and the AC disconnect is added to the electrical model. The same may betrue for distribution panels. This ability can be expanded to anyelectrical component. At 2006, the user may select components and placethe components in the design area. In one embodiment, differentelectrical components may have an associated draw count indicating thenumber of such components on the design area. When a user selects anicon for a particular component, the user may specify the location ofthe particular component in the design area. Each time an additionalcomponent of the same type is place in the design area, the draw countis incremented. As mentioned above, the user also has the option to drawelectrical components that are not determined to be obligatory.

Referring again to FIG. 19, both required and optional electricalcomponents for installing the system are displayed in electronichardware interface 2210, including an inverter 2211, meter main 2212,distribution panel 2214, AC disconnect 2215, and combiner 2213. Otherelectrical components that may be displayed for use in other solarprojects may include a DC disconnect, junction box, or a load center formultiple inverters, for example. Required components may be displayed inone color (e.g., red) and optional components may be displayed inanother color (e.g., white). The user may select component icons frominterface 2210 and place the components in the design area at particularlocations based on the physical attributes of the actual site. In thisexample, the user has placed a combiner box 2222 next to the modulearray 2221 for combining the electrical outputs of the solar panels. Aninverter 2223 is placed proximate to a location for the meter main 2224.In some embodiments, as required components are placed in the projectdesign area, the required components may be removed (not displayed) fromthe component interface 2210. Delete icon 2216 may be used to deletecomponents from the design area. When the required components areplaced, the user may select the lock icon 2217 to indicate completion ofthis process step.

FIG. 21A illustrates a process to draw conduit according to one exampleembodiment. In this example, a user may audit the site and determine adesirable conduit routing to install the solar energy system. Forexample, when a user selects the draw conduit icon 1226, an interface2310 is displayed for indicating the routing of AC and DC conduit in thedesign area of the project. For instance, when a user selects a DCconduit icon 2311, the system may allow the user to click and draw a DCconduit connection between combiner box 2222 and inverter 2223.Similarly, when a user selects an AC conduit icon 2313, the systemallows the user to click and draw an AC conduit connection betweeninverter 2223 and meter main 2224. Delete DC conduit icon 2312 anddelete AC conduit icon 2314 may be used to delete DC and AC conduit fromthe design area, respectively. In one embodiment, the system may requirethat the user start drawing conduit from the solar array, where currentand voltage are generated, and end in the meter. The system may onlyallow start and end points for conduit at acceptable locations based onelectrical properties of the components being connected by the conduit.For instance, DC outputs cannot be connected to AC inputs and AC outputscannot be connected to DC inputs. For example, conduit starting on acombiner may not finish on a meter. As the user draws conduit on theproject, the system may display to the user characteristics of theconduit such as string length, branch length, inverter output length,and combined inverter output length, for example. When the requiredconduits are configured in the project, the user may select the lockicon 2315 to indicate completion of this process step.

In one embodiment, after the components are placed and the conduitconfigured for the site, the system may prompt the user to selectbackfeed breakers by accessing and displaying data with backfeed breakerinformation as illustrated in FIG. 21B. Window 2350 displays differentbreaker panel brand, type, poles, size, amps, description, and bill ofmaterial (BOM). The user may select a particular panel from a drop downmenu and select an appropriate backfeed breaker based on a required OCPsize displayed in window 2350.

FIG. 22 illustrates a process to adding a safety plan according to oneexample embodiment. In this example, a user may audit the site and enterand configure the a variety of physical attributes of the site thatshould be taken into consideration when installing a solar energysystem. For example, when a user selects the add safety plan icon 1227,an interface 2550 is displayed for inserting physical attributes of thesite into the project in the design area. In this example, interface2550 includes an icon 2501 for placing a no ladder zone 2521 (e.g.,locations on the site where ladders may not be placed), an icon 2502 forspecifying acceptable locations for ladders (e.g., where the auditorplaced their ladder 2522 during the audit), an icon 2503 for specifyingthe location of a gate 2523 in a fence, an icon 2504 of specifying thelocation of utility lines 2524, an icon 2505 for specifying the locationof the front of a house 2525, an icon 2506 for specifying the locationof one or more trees 2526A-B (e.g., a tree may be specified byspecifying a first location with a mouse and specifying a radius for thetree), an icon for specifying distance between the edge of the house anda property line 2527 (e.g., a user may enter the actual distance betweenan object and the property line), an icon 2508 for specifying a driveway2322, and an icon 2509 for specifying a location of a water outlet 2529,for example. Interface 2550 may include a text entry area 2510 forentering notes corresponding to the safety plan, for example, a deleteicon 2511 for deleting one or more safety plan objects in the project,and a lock icon 2512 to finish the safety plan.

FIG. 23 illustrates engineering escalations according to one exampleembodiment. As mentioned above, features and advantages of someembodiments may allow a user to enter physical attributes (i.e.,parameters) of a design for a particular project into a mobile device,and the user may not be a highly trained design engineer. Accordingly,embodiments of the present invention may automatically analyze the datareceived from the user and determine if one or more aspects of theproject need to be escalated to a more highly trained engineer. Sincenot all engineers are trained in the same expertise or to the samelevel, this may include field engineers escalating aspects of a projectto design engineers in main office. In this example, interface 1201 fromFIG. 10 includes an engineering escalation icon 1212. A user may selecticon 1212 anytime during the design process and check to see if thereare any engineering escalations listed. In this example, escalations aredisplayed in window 2620, which illustrates example escalations entries.As the physical parameters of a project are entered into the system bythe user at each of the above described process steps, the physicalparameters may be analyzed against escalation rules that determine ifparticular parameters or particular combinations of parameters violatethe rules. If the rules are violated, an engineering escalation entrymay be created, for example. The following are example engineeringescalations and escalation rules applied to generate the escalations:

Engr. Esc.: “Multiple mounting plane systems need to be escalated toEngineering.”Esc. Rule: All multiple mounting plane systems may be sent toEngineering for verification.Engr. Esc.: “BOM Builder Not Completed for Job.”Esc. Rule: If there is an error in the process and building the BOMfails, an escalation is raised (e.g., this could be caused by theauditor not entering the appropriate roof type, an electrical diagramthat's too complex, or if the algorithm simply hits an error in CAD).Engr. Esc.: “Flat Roof Freely Drawn in Design Area”Esc. Rule: If a roof is freely drawn in the Design Area, it cannot havestructural calculations performed on it and it needs to be drafted inthe main office. This constitutes the job being sent to engineering.Engr. Esc.: “MP#: Rafter Upgrades needed”Esc. Rule: If a CAD drawn side view fails structural checks, then weneed to raise an escalation and have the structure analyzed in house.An example function from the Mounting Plane System class for generatingescalations is in Appendix G. In one embodiment, classes in the datamodel store their escalations. The MountingPlaneSystem recallsescalations before uploading them to computers at the main office.

Referring again to FIG. 10, when a user has completed each of theprocess steps displayed in interface 1201, a user may select thegenerating installation documentation icon 1228. In this example, icon1228 triggers the mobile device to generate installation documentationfor the solar power installation project based on the input data. Theinstallation documentation may be generated in the form of one or morePDF documents that include a permit set (e.g., permit informationprovided to a building department having jurisdiction over the projectlocation), single line drawings (e.g., electrical drawings provided to autility having jurisdiction over the project location), and constructiondocuments that may comprise a set of instructions for the installationcrews.

As mentioned above, some embodiments may modify a custom CAD template,which comprises blocks that fit together like legos. Templates mayaddress every permutation of a PV system. As described above, a mastertemplate may be modified to generate a custom template for a particularproject, and the custom template for the project is loaded into thesystem before performing the audit, for example. In one implementation,design requirements are stored in a database as rules linking jobinformation to instructions for modifying the master template. Forexample, the system may include the following SQL statement: select[State] from vCustomersInstallationsACAD where JobID=@JobID. If theresult of the query is “CA”, then system may modify the master template.The system may associate a modification indicator (or modification type)with a particular rule. For example, for the above SQL statement whichis executed and returns “CA”, the system may associate a parameterindicating that a block is to be added if the result is “CA”. The rulemay also be associated with one or more particular blocks to be added.The above SQL statement may be associated with a block name, an addressto access the CAD block, a specification of a portion of a block orattribute of the block to be modified, a priority, and/or a unique blockID. The following is one example:

Design Requirement:

SQL: select [State] from vCustomersInstallationsACAD where JobID=@JobIDSQL Result=True: CA (If SQL Result=CA, then modify master template)Remove: 0 (0=add a block; 1=delete a block)

Block Location: C:\Common\Installs\Drafting\TEMPLATE_BLOCKS.dwg BlockName: TAG NOTE COVER GEN NOTES CA

Attribute: PT_(—)1 (location to add text to block)Block ID: 1 (unique block ID)Priority: 1 (if two blocks are two be added to the same location, addblock with higher priority)

In the above example, for the state of California, the system may inserta general set of notes that are applicable to every county and AHJ forthe project location. In the first directive, the system may test to seeif the state is CA, and if so the system inserts a block onto the firstpage of the planset. Another design requirement may be as follows:

SQL: select [City] from vCustomersInstallationsACAD where JobID=@JobIDSQL Result=True: IRVINE (If SQL Result=IRVINE, then modify mastertemplate)Remove: 0 (0=add a block; 1=delete a block)

Block Location: C:\Common\Installs\Drafting\TEMPLATE_BLOCKS.dwg BlockName: TAG NOTE COVER GEN NOTES CA IRVINE

Attribute: PT_(—)1 (location to add text to block)Block ID: 6 (unique block ID)Priority: 5 (if two blocks are two be added to the same location, addblock with higher priority)

In the above case, a different block of text is to be inserted in thesame place as a previous block. In one embodiment, each designrequirement is associated with a priority. When two blocks aredetermined to be in conflicting positions in the custom template, theblock with the higher priority is inserted into the custom template.Above, the second design requirement pertaining to IRVINE would takeprecedence because the priority is 5 versus a priority of 1 for thedesign requirement pertaining to CA. The following two designrequirements illustrate deleting blocks from the master template. In thefirst case, D size pages are deleted, and in the second case, B sizepages are deleted:

SQL: select PlanSize from AHJ where AHJID in (select distinct [AHJID]from vAHJ where (ahjid in (select [AHJID] fromvCustomersInstallationsAHJ where jobid=@JobID) or utilityid in (select[utilityid] from vCustomersInstallations where jobid=@JobID))) andPlanSize < >″

SQL True: D Remove: 1 Priority: 1 Block Location:C:\Common\Installs\Drafting\Template_MASTER.dwg Block Name: B TEMPLATEVIEWPORTS Attribute: NULL Block ID: 29

SQL: select PlanSize from AHJ where AHJID in (select distinct [AHJID]from vAHJ where (ahjid in (select [AHJID] fromvCustomersInstallationsAHJ where jobid=@JobID) or utilityid in (select[utilityid] from vCustomersInstallations where jobid=@JobID))) andPlanSize < >″

SQL True: B Remove: 1 Priority: 1 Block Location:C:\Common\Installs\Drafting\Template_MASTER.dwg Block Name: D TEMPLATEVIEWPORTS Attribute: NULL Block ID: 28

As mentioned above, some embodiments may map limited user input actionsto multiple CAD functions. In a solar installation context, embodimentsof the present invention may receive limited user inputs for placing andspecifying a PV system at a site and generate a full model andschematics for the system. For instance, a user may complete the conduitrun step as described above. When the user selects the lock button, theelectrical data model is analyzed and translated into a CADrepresentation of blocks and BOM parts. The system automatically selectsthe blocks required to build a full 3-line electrical drawing includingblocks for each component placed by the user on the roof of the home andelectrical connectivity (wiring) between the components and descriptionsfor a plan set.

As another example, FIGS. 24-25 illustrate two mounting hardware blocktemplates for mounting hardware for Spanish Tile with a 6 inch standoffand another template for mounting hardware for Spanish Tile with and 8inch standoff. In this example, the system automatically selects blocksbased on whether or not the auditor places solar panel modules over avent on the roof, for example. These two templates may be used for allSpanish Tile roofs, for example. Bill of Material (BOM) blocks may beembedded in these templates, and their quantities may be updated by theprogram prior to the job being uploaded to computers (e.g., servers) atthe main office.

Accordingly, the mobile system may include numerous CAD blocks forphysical components (e.g., all available mounting hardware) andelectrical components. The user may provide simple limited userinterface actions to specify the solar design and the system maytranslate the limited user inputs into multiple CAD functions thatresult in a complete electrical model that represents the electricalproperties of the system. A full plan set may be generated automaticallyby accessing and compiling numerous blocks based on the generated CADfunctions, for example.

The Bill of Materials (BOM) may be contained within a CAD drawing. Themetadata may be stored in CAD blocks. As mentioned above, a block is anentity within the CAD database, which may have a unique stringidentifier for its name. When the audit project is completed anduploaded back to the main office servers, the software may populate theBOM on the main office servers. Blocks are useful both for their storageof the BOM metadata, but also for their ability to be viewed easily bythe end user in the output PDF, for example. BOM blocks may be embeddedthroughout the CAD files, and upon uploading the audit, the mobiledesign automation software may recursively search the CAD database,collects all the part numbers, and sends them to a database at the mainoffice. For example, part numbers may be loaded into a supply chainmanagement database, where the part numbers may be viewed and ordered bya user in a warehouse through the supply chain management software.

FIG. 26 illustrates relationships between inputs and outputs of anexample mobile design automation software system according to oneembodiment. A laptop, for example, may run a local version of a database2903. The database, which may include an engineering reference database,may include relationships. For example, electrical part numbers may beassociated with CAD representations as blocks (e.g., a Single Linedrawer figures out the mapping of an Electrical Model to a particularPart Number and then consequently the CAD representation). Further, AHJidentifications may be associated with actions to customize a mastertemplate (e.g., AHJ ID 853 could require that the Elevation Drawing pagebe deleted). Mounting Hardware Part Numbers may be associated with aparticular ‘Type.’ For example, a BOM builder component of the softwaremay parse the drawing and determine the quantities of each ‘Type’ in adesign. The software may then find all the BOM tags in the drawing, andfill in the appropriate quantities. BOM tags are determined from thetemplates, such as the templates described in the context of themounting hardware above.

In one embodiment, a master template may be used as a basis for all ofour permitting sets and construction plan sets generated by thesoftware. Each AHJ may require a custom permit set (e.g., at the citylevel every building department wants to see different items representedand taken into account when permits are applied for). Often these arepurely aesthetic items like simple notes or particular pages. A mastertemplate copied at the beginning of each audit and the newly copiedtemplate has actions applied to it from the AHJ database that mayrepresent additions or removals of pages or items, for example.

FIG. 26 further illustrates a mapping of particular inputs received bythe mobile design automation software 2900 to particular outputs. Inputsthat are preloaded are illustrated at 2902 and inputs received from theuser (e.g., an auditor) are illustrated at 2901. Outputs are shown at2930-2935. Relationships are illustrated by arrows. In this example, thestart of an audit (an initial custom formatted CAD file) is generatedfrom schematic 2920 (e.g., Precigeo), AHJ Requirements 2922, and aMaster Template 2926. A CAD file may be customized by a list of rulesstored in the database that dictate whether items should be added orremoved to/from an initial template. These rules may be based on AHJrequirements and geographic location of the job site, for example. Thecustom template may be required to pull a building department permit aswell as to help the auditor know what information needs to be collected.The custom template is a sub-version of the master template. Portions ofthe master template are removed and additions are made to form thecustom template. Shade Regions 2931 are automatically created by apreloaded latitude 2923 of the job site as well as the obstructions 2913input by the auditor. Shade regions may be important due to their impacton the performance of the solar panel system. The PV Design 2932 iscreated from the sales information (sales proposal) 2921 (e.g., thecustomer expectation from the sales person of what will be installed ontheir roof), the AHJ Requirements 2922 (e.g., how far the panels need tobe from the ridge or eave of the house), the schematic 2920, which maydictate the overall layout of the mounting planes, the Shade Regions2931 (e.g., to avoid putting modules in them), the Ambient Temperatureof the region 2924, which may dictates the available string lengths andwhether or not a design is plausible, available BOM Parts 2925 from thesupply chain (e.g., what modules are available), and the Module Layout2911 that the auditor draws on the roof, for example. The Bill ofMaterials and Quantities of Parts 2933 may be dictated by the RoofConditions 2910 (e.g., Comp Shingle, Spanish Tile, etc. . . . ),available BOM Parts 2925, the PV Design 2932 (whether the design spansvents), and the Structural Calculations 2934, which may dictate thequantities of the standoffs for the array, for example. The StructuralCalculations 2934 may be derived from the auditor's drawing of theStructural Information 2914 underneath the roof (e.g., where the 2×4'sare, what points they hit, whether or not they are load bearing) and thePV Design 2932 (e.g., specifically determining where the modules areplaced on the roof and their consequent point loads on the rafter in thesystem). The Single Line Drawing 2935 may be derived from the auditorsinput Electrical Information 2912 (e.g., what type of panel, whether ornot breakers are available, etc), the Ambient Temperatures 2924 (e.g.,what size wires are required for given temperatures), the available BOMParts 2925 from the supply chain, which may dictate what inverters areavailable, the PV Design 2932 which may specify how many modules atparticular tilts and azimuths need to be drawn, and the conduit routing2915 that the auditor draws in, which may change the wire sizes of thedifferent component connections based upon their length.

Example Implementation in Hardware

FIG. 27 illustrates hardware of a computing machine configured with amobile design automation process according to one embodiment of thepresent invention. As mentioned above, mobile design automation softwareaccording to some embodiments may be implemented on a laptop computer,tablet computer, or other portable computer system, for example. Anexample mobile computer system 3010 is illustrated in FIG. 27. Computersystem 3010 includes at least one bus 3005 or other communicationmechanism for communicating information, and one or more processors 3001coupled with bus 3005 for processing information. Computer system 3010also includes a memory 3002 coupled to bus 3005 for storing informationand instructions to be executed by processor 3001, including informationand instructions for performing the techniques described above, forexample. Possible implementations of this memory may be, but are notlimited to, random access memory (RAM), read only memory (ROM), or both.A storage device 3003 is also provided for storing information andinstructions. Common forms of storage devices include, for example, ahard drive, a magnetic disk, an optical disk, a CD-ROM, a DVD, anon-volatile memory (e.g., flash memory), a USB memory card, or anyother non-transitory computer readable medium. Storage device 3003 mayinclude source code, binary code, or software files for performing thetechniques above, for example. Storage device and memory are bothexamples of non-transitory computer readable mediums.

Computer system 3010 may be coupled via a bus to a visual display 3012for displaying information to a computer user. An input device 3011 suchas a touch screen, track pad, keyboard and/or mouse is coupled to a busfor communicating information and command selections from the user toprocessor 3001. The combination of these components allows the user tocommunicate with the system. In some systems, bus 3005 may be dividedinto multiple specialized buses of which bus 3005 is representative.

Computer system 3010 may include one or more network interfaces 3004.Network interface 3004 may provide two-way data communication betweencomputer system 3010 and a wired and/or wireless 3020, for example. Thenetwork interface 3004 may be a digital subscriber line (DSL) or a modemto provide data communication connection over a telephone line, forexample. Another example of the network interface is a local areanetwork (LAN) to provide a data communication connection to a compatibleLAN. Network interface 3004 may alternatively be a wireless interfacesuch as a cellular phone interface, 802.11, or Bluetooth interface, forexample. In any such implementation, network interface 3004 sends andreceives electrical, electromagnetic, or optical signals that carrydigital data streams representing various types of information.

Computer system 3010 may send and receive information through thenetwork interface 3004 across network 3020 (e.g., a local network orwireless network) which may include the Internet. Computer system 3010may communicate with a computer at a main office, such as server 3015(e.g., when an auditor is at the main office or remotely). Accordingly,computer system 3010 and server 3015 may send and receive informationpertaining to design projects to be processed according to thetechniques described above. The software components and processesdescribed above may be implemented on any computer system and sendand/or receive information across a network, for example.

The above description illustrates various embodiments of the presentinvention along with examples of how aspects of the present inventionmay be implemented. The above examples and embodiments should not bedeemed to be the only embodiments, and are presented to illustrate theflexibility and advantages of the present invention as defined by thefollowing claims. Based on the above disclosure and the followingclaims, other arrangements, embodiments, implementations and equivalentswill be evident to those skilled in the art and may be employed withoutdeparting from the spirit and scope of the invention as defined by theclaims.

1. A computer-implemented method comprising: displaying, in a graphicaluser interface of a mobile device, a plurality of icons and a designarea, wherein the plurality of icons correspond to different solar powerinstallation process steps, and wherein the plurality of solar powerinstallation process steps guide a user through a solar powerinstallation process for a project, and wherein the design area displaysthe solar power installation project; receiving, in the mobile device,selection of the icons; displaying, in the graphical user interface inresponse to selection of a particular icon, a process step specific userinterface, the process step specific user interface comprising aplurality of graphical components specific to particular solar powerinstallation process steps; receiving, in the mobile device, input datafor the solar power installation project from the user for the pluralityof solar power installation process steps, wherein the input datacomprises physical attributes of a solar power installation at aparticular installation site, and wherein the solar power installationproject is customized for the particular installation site based on theinput data from the user in the mobile device; and generatinginstallation documentation for the solar power installation projectbased on the input data.
 2. The method of claim 1 further comprisingreceiving a custom template, the custom template comprising a pluralityof computer aided design blocks tailored for a particular project,wherein the custom template is modified in response to said selection oficons and said receiving input data to produce said installationdocumentation.
 3. The method of claim 1 wherein the graphical userinterface receives a predefined set of user input actions, and whereinone or more of the user input actions are mapped to computer aideddesign functions, and the computer aided design functions are executedto modify predefined blocks in a template and to modify a model of thesolar power installation project.
 4. The method of claim 1 wherein theinstallation documentation comprises a bill of materials and engineeringdrawings for a particular authority having jurisdiction where said solarpower installation project is located.
 5. The method of claim 1 furthercomprising checking the input data for the solar power installationproject from the user and generating an engineering escalation if theinput data does not pass particular predefined criteria for said check.6. The method of claim 1 wherein the process step specific userinterface comprises a user interface for adjusting dimensions of abuilding structure.
 7. The method of claim 1 wherein the process stepspecific user interface comprises a user interface for specifyingobstructions on a surface of a building structure.
 8. The method ofclaim 1 wherein the process step specific user interface comprises auser interface for specifying mounting planes on a surface of a buildingstructure for mounting solar panels.
 9. The method of claim 1 whereinthe process step specific user interface comprises a user interface forconfiguring electrical components of a solar energy system, the methodfurther comprising validating the electrical configuration of said solarenergy system.
 10. The method of claim 1 wherein the physical attributescomprise electrical attributes and structural attributes.
 11. Anon-transitory computer readable medium embodying a computer program forperforming a method, said method comprising: displaying, in a graphicaluser interface of a mobile device, a plurality of icons and a designarea, wherein the plurality of icons correspond to different solar powerinstallation process steps, and wherein the plurality of solar powerinstallation process steps guide a user through a solar powerinstallation process for a project, and wherein the design area displaysthe solar power installation project; receiving, in the mobile device, aselection of the icons; displaying, in the graphical user interface, aprocess step specific user interface, the process step specific userinterface comprising a plurality of graphical components specific toparticular solar power installation process steps; receiving, in themobile device, input data for the solar power installation project fromthe user for the plurality of solar power installation process steps,wherein the input data comprises physical attributes of a solar powerinstallation at a particular installation site, and wherein the solarpower installation project is customized for the particular installationsite based on the input data from the user in the mobile device; andgenerating installation documentation for the solar power installationproject based on the input data.
 12. The non-transitory computerreadable medium of claim 11 further comprising receiving a customtemplate, the custom template comprising a plurality of computer aideddesign blocks tailored for a particular project, wherein the customtemplate is modified in response to said selection of icons and saidreceiving input data to produce said installation documentation.
 13. Thenon-transitory computer readable medium of claim 11 wherein thegraphical user interface receives a predefined set of user inputactions, and wherein one or more of the user input actions are mapped tocomputer aided design functions and the computer aided design functionsare executed to modify predefined blocks in a template and to modify amodel of the solar power installation project.
 14. The non-transitorycomputer readable medium of claim 11 wherein the installationdocumentation comprises a bill of materials and engineering drawings fora particular authority having jurisdiction where said solar powerinstallation project is located.
 15. The non-transitory computerreadable medium of claim 11 further comprising checking the input datafor the solar power installation project from the user and generating anengineering escalation if the input data does not pass particularpredefined criteria for said check.
 16. The non-transitory computerreadable medium of claim 11 wherein the process step specific userinterface comprises a user interface for adjusting dimensions of abuilding structure.
 17. The non-transitory computer readable medium ofclaim 11 wherein the process step specific user interface comprises auser interface for specifying obstructions on a surface of a buildingstructure.
 18. The non-transitory computer readable medium of claim 11wherein the process step specific user interface comprises a userinterface for specifying mounting planes on a surface of a buildingstructure for mounting solar panels.
 19. The non-transitory computerreadable medium of claim 11 wherein the process step specific userinterface comprises a user interface for configuring electricalcomponents of a solar energy system, the method further comprisingvalidating the electrical configuration of said solar energy system. 20.The non-transitory computer readable medium of claim 11 wherein thephysical attributes comprise electrical attributes and structuralattributes.